In message <199511040039.AA195075591@l-ecn046.icaen.uiowa.edu>Douglas Siebert writes: >I disagree quite strongly. Assuming your implementation of shared libraries >is sane, like HP's, you should not even have to worry about this class of >attacks. HP requires a compile-time option to the linker to ALLOW changing >the library search path via an environment variable. You can also change >this attribute on an existing binary using the 'chatr' (change attribute) >command. HP does that? Cool. That's exactly the sort of thing I'd like to see. It's struck me for some time that all the zillions of security holes we've seen with LD_* exist because the whole LD_* system violates a fundamental axiom of Unix security. It used to be that the only way you could change the code that got executed when you ran a program is to write to the executable file. That provided a certain level of security, in that in order to change the way, say, /bin/login works, you have to have previously broken root via some other means. :-) But now with the LD_* variables around, what code gets executed when you run an executable depends on what's in the environment, which is something that can be altered by malicious users. I seriously think that the people out there supplying Unix systems ought to make the default be that LD_* environment variables have no effect. Yeah, it's sometimes useful to have the ability to change what libraries a shlib-using executable is using, but it should be through some mechanism that requires changing to the executable file (like the 'chatr' mechanism the HPs have, or simply having the pathnames for the libraries be at standardized places in the executable -- at addrs given by some standard symbol, say -- so you can have a program that changes what libs a given executable will use.) That way, the axiom that you can't change what code a program executes without write access to the executable still holds. It occurs to me that it might not even be that hard to implement the equivalent of the 'chatr' attribute on other Unix-type systems. I gather that somewhere in the startup code for any program linked with shlibs there's code that loads in the dynamic linker (ld.so) and calls it, right? Well, all you need is to have two versions of ld.so, one respecting the LD_* variables and one that doesn't. Have the pathnames of the two versions differ by a single letter. Then all chatr needs to do is find that pathname in your executable and flip that one byte in the pathname to make your executable use the 'dangerous' ld.so instead of the safe one. -- Richard Todd rmtodd@mailhost.ecn.uoknor.edu rmtodd@servalan.uucp New Improved Domain: rmtodd@servalan.servalan.com